FINAL REPORT 


APPENDIX A 


DEFINITION OF AVIONICS CONCEPTS 
FOR A HEAVY LIFT CARGO VEHICLE 


for Marshal Space 
Contract Number 


Flight Center 
NAS8-37578 


September 1989 


GENERAL DYNAMICS 

Space Systems Division 


(NASA-CR-183617) DEFINITION OF AVIONICS 
CONCEPTS FOR A HEAVY LIFT CARGO VEHICLE, 

APPENDIX A Final Report (General Dynamics 
Corp.) 38 p CSCL OLD 

G3/06 


NR0-13380 

Unci as 
0243191 



! Report Documentation Page ' 

j ' -i * • - - H m .» ir, 1 1 ^ | 

1. Report No. 

| 

2. Government Accession No. 

3. Recipient's Catalog No. 

4. Title and Subtitle 

Definition of Avionics Concepts for a Heavy Lift Cargo 
Vehicle - Appendix A, Final Report 

5. Report Date 

Sept. 1989 

6. Performing Organization Code 

7. Aufhorls) 

8. Performing Organization Report No. 

10. Work Unit No. 

9. Performing Organization Name and Address 

General Dynamics 
Space Systems Division 
San Diego, CA. 

11. Contract or Grant No. 

NAS8-27578 

13. Type of Report and Period Covered 

Final 

03/88 - 09/89 

12. Sponsoring Agency Name and Address 

National Aeronautics & Space Administration 
Washington, D.C. 20546-0001 

14. Sponsoring Agency Code 


15. Supplementary Notes 


Prepared for Marshall Space Flight Center/PD14 


16. Abstract 

The major objective of the study task was to define a cost effective, multiuser 
simulation, test, and demonstration facility to support the development of avionics 
systems for future space vehicles. This volume provides the results of the main 
simulation processor selection study and describes some proof-of-concept demonstra- 
tions for the avionics test bed facility. 


17. Key Words (Suggested by Author(s)) 

Avionics 
Space Vehicles 
Test beds 
Simulation Labs 

I 

18. Distribution Statement 

unclassified - unlimited 


19. Security Classif. (of this report) 

20. Security Classif. (of this page) 

21 . No. of pages 

22. Price , 

unclassified 

unclassified 


36 



NASA FORM 1626 OCT 86 

For sale by the National Technical Information Service, Springfield, VA 22161-2171 




Fin^Re^n^A^end^ 


Definition of_Avionics Concepts for a Heavy Lift Cargo Vehicle 


TABLE OF CONTENTS 

Section : ESSfi 

1.0 INTRODUCTION ■•••• 3 

1.1 Scope 3 

1 .2 Background 3 

1.2.1 Follow-On Study Objectives 5 

2.0 GROUND BASED TESTBED MAIN PROCESSOR SELECTION STUDY 5 

2.1 Main Processor Candidate Screening 10 

2.2 Main Processor Benchmark Testing 1 3 

2.3 E.A.I. Evaluation 19 

2.4 Evaluation of the New Harris and Concurrent Computer Systems 20 

3.0 GBT CONTROL, MONITORING AND DISPLAY SOFTWARE 21 

3.1 Background 21 

3.2 GBT Philosophy 21 

3.3 GBT Software Architecture 22 

3.3.1 Software Architecture Characteristics 22 

3. 3. 1.1 Real-time Simulations Multi-Processor Based 22 

3. 3. 1.2 Phases of Flight 23 

3.3.1 .3 Integration of Avionics Hardware Into Real-Time 

Simulations 23 

3. 3. 1.4 Real Time Simulation of Avionics Hardware 23 

3. 3. 1.5 Fault Insertion Capabilities 23 

3. 3. 1.6 Stand-Alone Avionics Hardware Testing 23 

3.3.1 .7 User Friendly Interface 23 

3.3. 1.8 Multiple Users 23 

3.3.2 Menu Architecture 24 

3.3.3 Menu Design 25 

3.3.3. 1 Main Status and Allocation Menu 25 

3.3. 3. 2 Hardware Status and Allocation Menu ...26 

3. 3. 3. 3 Test Control and Monitor Menu 27 

3. 3. 3. 4 Test Selection Menu 28 


Page i 


10/11/89, 11:58 AM 



Final Report. Appendix A 


Definition^of^Avionics^Concepts for^a Heavy Lift CarqoJ/ehjcle^ 


Section P^Slfi 

3.3.4 Simulation Models 29 

3.3.4. 1 Mission/Vehicle/Environment Models 29 

3. 3. 4. 2 Avionics Simulation Models ...29 

3.4 GBT Design Concept Demonstrations 30 

3.4.1 May Demonstration 31 

3.4.2 June Demonstration 31 

3.4.3 September Demonstration 32 

3. 4.3.1 Demonstration Objectives 33 

3. 4.3.2 Modular Vehicle Dynamics Software 34 

3.4. 3. 3 Shuttle C, Hardware in the Loop Demonstration 34 

3.4.4 Proposed December Demonstration 34 

3.4.4. 1 Lab to Lab Data Communications 34 

3.4. 4. 2 Integration of New Propulsion Lab Resources 35 


Page ii 


10/11/89, 11:58 AM 





Definition ofAvionics Concepts for a Heavy Lift Cargo Vehicle 


1.0 INTRODUCTION 

Appendix A to the Final Report, of the National Aeronautics & Space Administration study, 
"Definition of Avionics Concepts for a Heavy Lift Cargo Vehicle" was written by the Space 
Systems Avionics Group of General Dynamics. It was performed under contract NAS8-37578 
for the Marshall Space Flight Center. 

1.1 Scope 

This document contains: 

• Results of the Main Processor Selection Study 

• Description of the Avionics Testbed Demonstration 

Most Main Processor Selection material and Demonstration hardware and software 
descriptions are contained in this volume. Any material felt to be in conflict with material 
previously presented in the Final Report or Preliminary Design Document should be viewed 
as more current and supersedes the older material. 

1.2 Background 

The HLCV avionics study was originally meant to focus the development of advanced 
avionics systems for various space vehicles for the next ten to fifteen years. Figure 1 .2-1 
shows the role the HLCV Avionics study was envisioned to play. Scoped to start with an 
expendable, Shuttle derived booster, it was to define an optimum progression of upgrades 
and transitions until a fully reusable fixed wing booster system was achieved. Not limited to 
boosters, the study was to explore second stages, recoverable modules, and the attendant 
ground support systems. 

Methods for accelerating the application of beneficial new technologies to existing and future 
systems were needed. To this end, a Ground Based Testbed was to be defined. Though not 
a stated goal, lowering the overall cost per pound of orbiting a payload drove the study to 
include the definition of the optimal mix of ground and airborne check out capability. 
Autonomous operation of the far term vehicles was felt to be a logical goal. 

Shortly after the first review, the customer directed a shift in emphasis to a more detailed 
definition of the Ground Based Testbed, (GBT), that would support development of the HLCV 
avionic systems. The HLCV reference vehicle avionic systems were defined to the level 
required to size the GBT main processor, G&N Extension, and interconnecting busses and 
networks. 

A target implementation schedule was provided by MSFC in October linking the HLCV GBT 
and the Marshall Avionics System Test bed (MAST) efforts (see Figure 1 .2-2.). Also defined 
were specific functional support levels with dates and projected budget allocations A 
candidate site for the GBT/MAST was also provided The third Quarter Review reflected these 
inputs and specifically costed the Phase 1 lab configuration. For purposes of this study the 
terms MAST and GBT are synonymous. 


Final Report, ApoendixA 


Definitbn of Avionics Concepts for a Heavy Lift Cargo Vehicle 



FIGURE 1.2-1. HLCV AVIONICS STUDY: FOCUS FOR AVIONICS ADVANCED DEVELOPMENT 
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FIGURE 1.2-2 HLCV / MAST IMPLEMENTATION 
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Two follow-on tasks were added to the study in March 1989. They included continuation of 
the Main Processor Selection effort and two Ground Based Testbed Conceptual 
Demonstrations. Appendix A was added to the Final Report to document the results of these 
efforts. 

* 

1.2.1 Follow-Op Study Objectives 

As stated in the revised Statement of Work: 

The contractor shall perform a detailed evaluation of several host simulation 
computer systems for the Avionics test bed. This activity shall include additional 
evaluation of the two primary candidates identified during the initial phase of this 
study together with the evaluation of two or more alternatives. The contractor shall 
support benchmark runs on the candidate systems to verify performance. 

Results of this study are reported in Section 2 entitled Main Processor Selection study. 

t 

The second major objective was specified as being: 

The contractor shall perform a demonstration of the avionics test bed concept 
defined in Task 5.4(b) to drive out and refine the test bed hardware and software 
requirements. Major objectives are to further identify and demonstrate system 
software characteristics which can be implemented to achieve user friendliness and 
rapid configuration for the test bed and to demonstrate the ability to rapidly and 
efficiently interface with and to close the simulation loop around flight-type 
hardware. The demonstration shall be performed at MSFC, utilizing a government 
provided simulation computer, three-axis table and launch vehicle dynamics and 
environmental models. The contractor shall perform the demo design, integration, 
and tests and shall provide the software for simulation monitoring and control 
to gether with TVC actuator, RCS thruster and avionics software models . The 
contractor shall also provide for the duration of this task appropriate GN&C and 
interface hardware to support the. evaluation of hardware in the loop simulation 
capability. 

Results of the demonstrations performed are reported in Section 3. 

A subset of the second major objective was identified as: 

The contractor shall also identify and demonstrate system software characteristics to 
achieve user friendliness and rapid reconfiguration for the test bed. 

Its results are reported in Sections 3 & 4. 

2.0 GROUND BASED TESTBED MAIN PROCESSOR SELECTION STUDY 

The functional requirements for the GBT Main Processor were dominated by several key 
issues. The GBT architecture and the philosophy upon which it was based was perhaps the 
more dominant of these issues. Figure 2.0-1 shows the target lab functiortal configuration. 
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The processors initial role is to be able to simulate a Phase 1 HLCV avionics system in its 
real time operational environment. This must be done with sufficient fidelity that the avionic 
system concepts and resulting designs may be accurately evaluated against accepted 
benchmark performance standards. The other end of the Main Processor operational 
continuum requires it to control and supervise the avionics hardware testbed and other 
resources in providing a "native" operational environment to the Units Under Test (UUT). The 
latter requires a parallel processor capable of sharing fast global memory with satellite labs 
and processors. The ability to efficiently interface with high speed data bases with a 
minimum of loss to overhand is essential. 



Sizing of the Main Processors throughput is driven by the type of simulations it must run in 
real time. Figure 2.0-2 shows a typical hardware in the loop simulation of a three string 
Phase 1 avionics system. Note the interaction of each functional software module. Figure 
2.0-3 quantifies this simulation at between 177.4 to 214.2 Millions instructions per second 
(MIPS). Figure 2.0-4 shows the comparative number of instructions for each element of the 
simulation. Note the number of instructions required by vehicle Dynamics and Body Bending 
modules. Figure 2.0-5 shows the through put requirements of the same simulation elements. 
Note the overwhelming requirement of the Actuators. Figure 2.0-6 depicts the parallelization 
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of the overall simulation showing module assignments of four typical processors. Note the 
assignments were based on 5.8 MIPS CPUs. The selected processor uses RIS architecture 
and has +20 MIPS capability. 
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FIGURE 2.0-3. TYPICAL SIMULATION SOFTWARE THROUGHPUT 
(SINGLE VEHICLE, MEDIUM FIDELITY, 3-STRING AUTOPILOT AVIONICS ON HOT BENCH) 
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2.1 Main Processor Candidate Screening 

Figure 2.1-1 reviews the main criteria/requirements upon which the initial paper study was 
conducted. Figure 2.1-2 shows the companies/products evaluated in the paper study from 
which the final screening candidates were chosen. 

Note the diversity of computers considered. They ranged from general purpose to highly 
specialized processors. Figure 2.1-3 reviews this continuum and the associated 
applications. 

The initial screening for the Main Processing System was based upon the following 
requirements: 

• Real time operating system 

• Global/shared memory support 

• High I/O & throughput rates (as directed by the simulation requirements) 

• Interface with avionics hardware 

• Scaleability with minimal software impact 

• Productive development environment 

• Minimize re-development of existing software models 

• Capable of hosting expert systems 

Figure 2.1-4 shows the criteria for final screening and the resulting candidates selected for 
the benchmark performance tests. 


REAL-TIME SIMULATION REQUIREMENTS 
(minimum support for advanced launch vehicle test-beds) 
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FIGURE 2.1-4. SELECTION CRITERIA/CANDIDATES 


2.2 Main Processor Benchmark Testing 

Due to the importance of the Main Processor Selection, a performance evaluation between 
the final two candidates was performed. Several tests were run by BBN and Concurrent 
Computers. Figure 2.2-1 outlines the tests run. These tests included five industry 
benchmarks, a Space Shuttle Main Engine Simulation provided by MSFC and an Ascent 
Simulation provided by GDSS. Results of these initial tests are shown in Figure 2.2-2. 

To understand the test results one must first understand the processors evaluated and their 
attendant architectures. The resulting differences in architectures and data processing 
strategies should logically be manifested in the test run. Table 2.2-1 highlights some of the 
differences of the units available for testing. 
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• PERFORMED FOR GDSS BY CANDIDATE VENDORS 

• DHRYSTONE, (INDUSTRY STANDARD) 

- Tests typical Integer system software mix 

- 53% assignments, no I/O, 47% array Indexing and Integer math 

- Cache based architectures will do very well here 

• WHETSTONE (INDUSTRY STANDARD) 

- 65% Integer Instruction 35% floating point 

- Exponential and transcendental functions 

/ 

• LINPACK (INDUSTRY STANDARD) 

- Heavy floating point computations 

- Matrices and linear operations 

• SSME SIMULATION (MSFC) AND MODIFICATIONS 

- Provide a measure of performance relative to existing systems at MSFC 

• ASCENT PHASE SIMULATION (GD/SS) AND MODIFICATIONS 

- Demonstrate parallel operation of an existing simulation 

- Yield relative before/after time comparisons 

FIGURE 2.2-1. TECHNICAL DEMONSTRATION • BENCHMARKS 
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FIGURE 2.2-2. TECHNICAL DEMONSTRATION - BENCHMARK RESULTS 
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BBN 

Concurrent 

• Memory is segmented into local 4K blocks 

• All memory is global 

• Highly De-centralized architecture 

• Centralized bus architecture 

• Memory is limited to 4 MB or 1 6 MB per processor 

• Limited to 1 6 MB total data memory 

(phase 1 (16* 4MB), target (15 * 16MB)) 
• No pipelined instructions 

■ Each processor has a 40stage pipeline and two (2) 

• All data fetches on non-local memory must 
ao throuah the butterfly switch 

8K caches (1 instruction and 1 data) 


TABLE 2.2-1. UNIT DIFFERENCES 


The BBN architecture links a large number of parallel processing modules via a proprietary 
"Butterfly Switch". The Concurrent architecture links its processing modules via a more 
conventional 256 MBS backplane. BBNs operating system through real-time, is not as 
developed as Concurrents. BBNs expandability looks better, but Concurrent has deployed 
systems that had throughputs of 1 50 MIPS. BBNs architecture should permit better parallel 
processing speeds and scale up more easily. 


SSME PROGRAM 

• Instructions (MIPS) Estimate 

- 4073 Instructions * 50 khz loop time = 203.65 MIPS 

- 100 sec simulation * 203.65 MIPS = 2.0365 x 10 10 instructions 

• Floating-point operations (FLO) estimate 

- 1170 FLO * 50 khz loop time = 58.5 MFLOPS 

- 100 sec simulation * 58.5 MFLOPS * 5.85 x 10 9 FLO 

• Tech demo performance 

- single-processor 

- present processor MIPS and MFLOPS rates 

(based on SSME program) 

Actual Actual Actual 

Simulation Time MIPS rate MFLOPS rate 

(SSME benchmark) 

BBN 29:08:00 = 104,880 sec 0.194 MIPS 0.056 MFLOPS 

Concurrent 1:11:00 = 4,260 sec 4.781 MIPS 1.373 MFLOPS 

FIGURE 2.2-3. TECHNICAL DEMONSTRATIONS - PROJECTIONS 

The industry standard benchmarks are primarily aimed at single processor performance 
evaluations and are NOT as representative in predicting performance of GBT tasks as are the 
two simulation benchmarks. Figure 2.2-3 details the MSFC SSME benchmark and the 
comparative results of the candidates. Figure 2.2-4 shows the results of the GDSS provided 
identical assistance to the candidates in parallelizing the benchmark simulation programs. 
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Figure 2.2-5 and 2.2-6 show the initial approaches suggested to both candidates for the 
SSME and Ascent Programs respectively. 


DYNAMIC SIMULATION (ASCENT) PROGRAM 

• Instructions (MIPS) Estimate 

- 10 sec simuiation * 13.5 MIPS = 135 * 10 6 instructions 

• Floating-point operations (FLO) estimate 

- 10 sec simulation * 5.02 MFLOPS = 5.02 x 10 9 FLO 

• Tech demo performance 

- single-processor 

- present processor MIPS and MFLOPS rates 

based on Dynamic Simulation program) 


Actual Actual Actual 

Simulation Time MIPS rate MFLOPS rate 

(Dynamic Sim benchmark) 

BBN 594sec 0.227 MIPS 0.085 MFLOPS 

Concurrent 


FIGURE 2.2-4. TECHNICAL DEMONSTRATIONS - PROJECTIONS 



P ROC #7 

PROC #8 

PROC #9 

T W1 5 

DW FD2 

T W1 4 

TJV2.5 

DW_4 

E_OPO 

DW FN 

TW2 4 

DW_OS 

PJ4FVD 

P_OP 

TCCV 

RHO 4 

DWOPF 

T MOV 

P 9 
P_POS 


TMFV 

226 

223 

221 

FLO 

FLO 

FLO 



* All state variable computations and integrations performed independently 

* Computations spread out over 12 processors 

* Longest computation path length in an individual processor is 226 FLO (floating point operations) 

* Original program (no parallelization) path length is 1 1 70 FLO 

* Predicted execution time for parallel version: 

226 / 1170 = 0.193 'unparallelized execution time 

* Time for 100 sec simulation on Concurrent (present processor) 

4260 sec (actual unparallelized execution time) 

=> 0.193 * 4260 sec = 822 sec (parallel execution time) 

* Time for 100 sec simulation on Concurrent (with 20 MFLOP vector processor) 

1.373 MFLOP (present processor) 

' 822 sec = 56 .4 sec 

20 MFLOPS (vector processor) 


FIGURE 2.2-5. SSME DEMO PROGRAM PARALLELIZATIO 
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LOW FREQUENCY TASKS 



Longest computation path length: 

5200 instructions (INST), 2875 floating point operations (FLO) 

Parallelized predicted execution time: 

5200 INST / 13530 TOTAL INST = 0.384 * unparallelized execution time (based on instructions) 
1875 FLO / 5019 TOTAL FLO = 0.374 * unparallelized execution time (based on FLO) 


FIGURE 2.2-6. DYNAMIC SIMULATION (ASCENT) DEMO PARALLELIZATION 


Based upon these initial test results, projections were made on the future performance of the 
candidates. Figure 2.2-7 shows those projections. 

At this point, Concurrents performance was clearly demonstrated to be closer to their 
advertised capabilities. BBN was hurt in that the unit available for test didn't represent the 
greater enhanced capabilities of their 88000 based model about to be released. This 
however, didn't mitigate BBNs optimistic claims for their current models performance. 
Concurrent also had a mature real-time operating system capable of handling the GBT 
requirements now and in the future. BBNs new unit would use an operating system yet 
unproven. 

At this point BBN effectively dropped out of further testing due to a reorganization of their 
local marketing organization. 
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DESCRIPTION 

ADVERTISED 
SINGLE NODE FIGURES 

ACTUAL 

SINGLE NODE FIGURES 

PHASE t 

! TARGET 


TARGET | 

BBN 

CONCURRENT 

BBN 

CONCURRENT 

mm 

■A15MII:l=HJkl 

■aga 


MIPS 

2.5 

6.4 

17 

6.4 

0.8 

6.6 

5 

6.6 

MFLOPS 

0.5 

1.2 

20 

41.2 

0.96 

1.3 

4 

213 

i/O (MBs) 

2 

40 

512 

40 

2 

40 

2 

40 

Bus Speed (MBs) 

4 

64 

40 

256 

4 

64 

4 

64 

Memory Capacity (MB) 

4 

256 

16 

256 

4 

256 

4 

256 

# of Processors 

1 

1 

1 

1 

1 

1 

1 

1 


ACTUAL PERFORMANCE FIGURES 

ACTUAL PERFORMANCE FIGURES 


PHASE 1 

TARGET 

PHASE 1 

TARGET 


BBN 

CONCURRENT 

BBN 

CONCURRENT 

BBN 

CONCURRENT 

BBN 

CONCURRENT 

MIPS 

40 

76 8 

272 

153 6 

12.8 

79.2 

80 

158 4 

MFLOPS 

8 

14,4 

320 

988.8 

1.536 

15 6 

64 

5112 

I/O (MBs) 

2 

40 

512 

40 

2 

40 

2 

40 

Bus Speed (MBs) 

4 

64 

40 

256 

4 

64 

4 

64 

Memory Capacity (MB) 

64 

256 

256 

256 

64 

256 

64 

256 

# of Processors 

16 

12 

16 

24 

16 

12 

16 

24 


PHASE 1 DELTA 

TARGET DELTA 





BBN 

CONCURRENT 

BBN 

CONCURRENT 




' ' 


0.32 

1,03125 

0 29411765 

1.03125 






0.192 

1 083333333 

0.2 

0.51699029 






FIGURE 2.2-7. TECHNICAL DEMONSTRATIONS - PROJECTIONS 


Since the selection of the Main Processor was so important in assuring the GBTs success, 
two more candidates were given the opportunity to run the performance benchmarks. They 
included Harris and E.A.I.. The groundrules remained the same for both new participants. 
Some new factors, however, were now being considered in the final selection of vendor for 
the Main Processor. These factors centered about the introduction of a new generation of 
computers which utilized the Reduced Instruction Set (RISC) CPU chip sets. Since their 
introduction was eminent, a new effort was launched to evaluate their added capabilities 
against the advantages of using currently available, more mature systems. One factor which 
was drastically apparent from Concurrent was a favorable shift in the price to performance 
ratio. The original - modef 3280 Phase 1 unit with required peripherals cost about $1.4M. The 
new RISC unit had twice the performance at about half the price. This permits Phase 1 
compliance with Phase 3 throughput requirements. 

Two of the remaining candidates were involved in this development of new products using 
RISC processors. E.A.I. was investigated since their Analog/Digital hybrid had successfully 
been used to model the Shuttle Main Engines and were prime candidates for use in the new 
propulsion system laboratory. 

Harris and E.A.I. were both provided the same data for running the benchmarks formally run 
by Concurrent and BBN. Harris completed the benchmarks using their Night Hawk 3000 
using a single CPU. Table 2.2-2 summarizes the results and compares them with the 
Concurrent results using a single CPU. 

Figure 2.2-8 compares the current Harris and Concurrent systems. 
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SS ME 

ASCENT 


MFGR 

FORTRAN PROGRAM 

C-PROGRAM 


Harris 

2 hrs 6 min 6 sec 

2 min 55 sec 


Concurrent 

1 hr 1 1 min 27 sec 

1 min 42 sec 



TABLE 2.2-2. HARRIS & CONCURRENT SINGLE CPU BENCHMARK RESULTS 


ISSUE 

CONCURENT 

HARRIS 

Throughput 

6.4 MIPS/CPU (9.4 Var MIPS) 

6 WHETSTONE MIPS/CPU 

Bus Bandwidth (Mbyte / s) 

256 sustained 320 max 

80 

On-Board Memory 

512 MB (Global Memory) 

8 MBYTE 

Growth Capabilities 

3280E-12 Processors 

MC88000 RISC (15 MIPS) 


RISC (20+MIPS/CPU) MIPS Chip 

4 CPU/board 

Processor Type 
S/W Compatibility 

Proprietary Bit Slice 

MC68030 

Op Sys 

OS/32 same OS for RT& Development 

Real-Time Unix 

PHIGS 

YES (MC and PSITECH Board) 

Yes 

GKS 

Yes (MC) 

Yes 

Xwindows 

Yes (MC) 

Yes 

IGES 


FORTRAN 

Yes 

Yes 

C 

Yes 

Yes 

Ada 

Yes 

Yes 

Interrupt Structure 

4 levels (1024/level/processor+20) 

87 Prioritized 

Connectivity 

E bus to E bus 

Shared Memory & Interrupts 

VME Throughput 

6MB/S/VMEB1 -FOSB1 10MB/S 


Cabinets 

3 

1 

Open System 
PERFORMANCE 
FORTRAN Benchmark 

NO (RTU-Yes) 

Yes 

1 Processor 

1:11:27 

2:06:06 

2 Processors 

0:53:32 

Not Run 

C Benchmark 
Current Capability 

0:1:42:00 

0:02:05 

Through-Put Max 

104 MIPS (256) 

46 


FIGURE 2.2-8. CONCURRENT/HARRIS COMPARISON 


2.3 E.A.I. Evaluation 

A basic problem was encountered in trying to evaluate the E.A.I. SimStar computer. Though 
E.A.I. was very responsive in providing basic performance data on their products, they would 
not run the benchmarks provided since the benchmarks were designed to evaluate primarily 
digital computers and were in a incompatible form. The E.A.I. machines were basically 
custom units built from "off-the-shelf" modules. They had successfully run 'a real-time 
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simulation of the Shuttle SSME which was much higher fidelity than the MSFC benchmarks 
used in our evaluation. 

After several discussions with the local E.A.I. representatives, we came to an agreement that 
the E.A.I's performance'on the SSME program demonstrated their clear superiority in that 
type of task. The other requirements which were covered in Figure 2.2-1 could not all be 
satisfied by this type of hybrid computer. The E.A.I., in short, would be an ideal resource 
upon which many simulations could be run, but its architecture would limit, if not preclude, it 
from functioning successfully as the Main Processor in the GBT. 

2.4 Evaluation of the New Harris and Concurrent Computer Systems 

Harris and Concurrent had clearly demonstrated that their advertised and measured 
performance levels were reasonably close. Their credibility was also enhanced by strong 
followings throughout GDSS. With Concurrent and Masscomp merging, their respective 
stability was felt to be enhanced. Harris had recently recommitted to a real-time simulation 
emphasis with their Night Hawk computers. 

The Main Processor selection study at this point, based on current performance and 
specifications, would have recommended purchase of the Concurrent 3280 processor. 

Since the originally projected purchase date had passed and been delayed nearly a year, a 
reevaluation was clearly needed. It would look at the new products available in the new time 
frame. 

Both Concurrent and Harris were invited to identify their new products available in the 
January 1990 time frame. Simple proprietary briefings were given. From these briefings a 
revised Phase 1 Main Processor Configuration was developed. Both manufacturers priced a 
system which would meet these preliminary requirements. 

Due to the proprietary nature of the briefings and the respective designs and schedules 
covered, only general results can be covered. Concurrent and Harris had both been looking 
at similar RISC chip sets. Concurrent had started a development program several months 
before Harris, having already selected a RISC chip set. Both had Real-time operating 
systems, Ada compilers and the other software tools required. Concurrent had products 
(Masscomp computers) in the field with a real-time UNIX operating system. At the time of the 
briefing, Harris had not delivered a multiprocessor (more than 3 CPUs) NightHawk to an 
outside customer. 

Based on Concurrent's experience with multiprocessor systems, head start on its RISC unit 
development and its willingness to commit to beta unit delivery by January 1990, it was felt to 
be the best choice. Price also had a very significant influence on the choice, as did a 
software development strategy. Concurrent's price for the Phase 1 unit was significantly 
lower than Harris. Concurrent also offered a Masscomp unit for software development by 
October. It's software was guaranteed to be transportable to the new GoldRush (RISC unit). 
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3.0 GBT CONTROL, MONITORING AND DISPLAY SOFTWARE 

3.1 Background 

The Ground Based Testbed concept rests heavily on its ability to integrate existing and 
emerging test laboratory resources into a versatile, cost effective testing facility. Key to this 
goal is the Control, Monitoring and Display, (CM&D), software whose architecture was 
defined and demonstrated in this study. 

3.2 GBT Philosophy 

The major points upon which the GBT design philosophy is based are: 

a. Reconfigurable Design 

b. Real Time 

c. Functional Testing 

d. Modular Design 

e. Flexible 

f. Demonstration Oriented 

g. User Friendly 

The broad based, non project dedicated, generic nature of the GBT is implied in the first 
point. The GBT must be an evolving facility, capable of supporting several current and near 
term avionic systems. This translates to a firm requirement for rapid reconfigurability. It must 
not only be able to switch from one test configuration to another, but it also must have 
sufficient capability to support several parallel efforts simultaneously. These efforts will 
include everything from basic evaluation of single units in an open loop environment, to full 
up, multi-string system simulation. 

To be truly useful to a number of projects simultaneously, the GBT must accommodate a 
variety of software and hardware configurations. This characteristic encompasses several 
traits which include an continuing capability to support several current and near term avionic 
systems. Implicit to this capability would be a rapid and easy reconfigurability made possible 
by an architecture that presents a broad compatibility to both hardware and software. This 
compatibility includes the ability to provide a Real-Time hardware and software interface. 

This interface must be capable of duplicating the normal interface the Unit Under Test 
encounters in its native system. Only with such an interface can testing and evaluation be 
carried out at the required level of fidelity. Just as important is the ability to precisely 
manipulate the interface characteristics. Fault insertion and off limit operation can enhance 
the thoroughness of testing. 

The GBT is modular at all functional levels so, as it develops and the support requirements 
change, the lab can add or access the required resources. This translates to the GBT being 
able to accommodate any vehicle or system simulation of similar complexity to the then 
current defined reference vehicle and systems. Modular design in both the GBTs hardware 
and software facilitate an orderly expansion of capability. The foundation of hardware model 
benchmarks will be validated against real equipment. Once proven, a combination of real 
and simulated hardware models can be utilized to evaluate any number of proposed system 
architectures. 

Since one of the GBTs primary functions is to provide timely support to new,projects, it must 
have the ability to quickly adapt to the specific needs of those projects. This flexibility must be 
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a basic consideration in the GBT architecture so it can perform that level of testing or 
simulation required in a more cost effective manner than currently available to new projects. 

3.3 GBT Software Architecture 

GBT lab software and the attendant displays fall into two general categories. The first deals 
with lab management and running tests while the second deals with the development of 
testing procedures, simulation data, test analysis, output graphics and report generation. The 
first type, called Control, Monitoring and Display, (CM&D) software has specific operational 
requirements which must be reflected in each menu and its supporting programming. The 
second type, called Task Development, (TD), software primarily involves linkage and / or 
tailoring of existing program modules and datasets to produce task oriented software. These 
TD programs are controlled 

3.3.1 Software Architecture Characteristics 

3. 3. 1.1 Real-time Simulations Multi-Processor Based 

The software supports real-time, multi-processor based simulations of existing or new 
unmanned vehicles including Shuttle-C, Centaur, OMV, STV, and ALS. The software is 
structured to take advantage of the multi-processor host computer to meet the simulation 
speed requirements. Additionally, the software is structured to allow variable frame-times for 
the individual software modules. An example of the multi-processor, variable frame time 
structure is shown in figure 3. 3. 1.1-1. 


Instructions per frame 


Processor 

#1 


Processor 

#2 


Processor 

#3 


Processor 

#40 


Input 

1501 

Act 1 
(400) 

Eng 1 
(141) 

Vehicle 

Dynamics 

(1481) 

Act 1 
(400) 

Eng 1 

(141) 

Vehicle 

Dynamics 

(1481) 







Atmosphere 
Gravity 
Grav Grad 
Aero (1468 

Input 

1501 

Act 2 
(400) 


ACS 1-10 
(1240) 

Act 2 
(400) 








Input 

1501 

Act 3 
(400) 

Eng 2 
(141) 

ACS 10-20 
(1240) 

Act 3 
(400) | 

Eng 2 
(141) 

ACS 10-20 
(1240) 


* 

* 

* 





Input 

1501 

Act 40 
(400) 



Act 40 
(400) 



H ■ " ■ — 2 msec {500 Hz)’ 


Act 1 
(400) 


Act 2 
(400) 


Eng 1 
(141) 


Vehicle 

Dynamics 

(1481) 


Mass Proos 
10-15 
( 1100 ) 


Act 3 
(400) 


Eng 2 
(141) 


Body 

Bending 

( 1000 ) 


Act 40 
(400) 


• Fastest processing requirements in processor #1 

- 41215 instructions / 2 msec => 20.6 MIPS 

• Other processor requirements 

- Actuator and engines computations 

- 1 1 595 instructions / 2 msec => 5.8 MIPS / processor 

• Low frequency computations (atmosphere, gravity, etc.) 

- Performed in any available time "slots* 


Output 

(625) 


Output 

(625) 


Output 

(625) 


Output 

(625) 


M 


FIGURE 3.3.1. 1-1. TYPICAL PARALLEL-PROCESSING TIMING DIAGRAM (SINGLE VEHICLE, 
MEDIUM FIDELITY, 3-STRING AUTOPILOT AVIONICS) 
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3. 3. 1.2 Phases of Flight 

The software is structured to allow the capability to simulate any phase of flight including pre- 
launch, ascent, on-orbit, re-entry and landing. This capability allows the simulation of both 
individual flight phases 'and an integrated mission consisting of multiple flight phases. 

3. 3. 1.3 Integration of Avionics Hardware Into Real-Time Simulations 

The software provides interface routines to drive appropriate I/O hardware. These routines 
and associated I/O hardware have the capability of reading from and writing to existing 
and/or new avionics hardware in a real-time manner. The avionics hardware to be supported 
includes Guidance and Navigation systems, Controls interface, data acquisition system and 
power systems. 

3. 3. 1.4 Real Time Simulation of Avionics Hardware 

The software modules perform real-time and non-real-time simulations of existing or new 
avionics hardware. These modules are in varying levels of fidelity to meet necessary real- 
time requirements. The software allows the simulation of multi-string avionics hardware by 
the use of multiple software modules and/or actual hardware. 

3. 3. 1.5 Fault Insertion Capabilities 

The software allows for the simulation of vehicle/subsystem faults and avionics hardware 
faults. Manual, pre-canned and random fault-insertion capabilities are provided. 

3. 3. 1.6 Stand-Alone Avionics Hardware Testing 

The software provides the capability to perform stand-alone testing of existing and/or new 
avionic hardware. This capability is independent of the main simulation, though individual 
simulation routines are used when necessary. The stand-alone testing has an acceptance 
test procedure (ATP) type of format, providing stimuli to the hardware and monitoring 
appropriate hardware responses. The software is structured to allow for a variety of test 
lengths and includes automatic, semi-automatic and manual test capabilities. The semi- 
automatic and manual test modes are such that an operator can manually select which 
hardware inputs to stimulate and which hardware outputs to monitor. Additionally, the 
operator may manually start the execution of any pre-programmed automatic test sequences. 

3. 3. 1.7 User Friendly Interface 

The software provides a user-friendly interface based on a tree-structure and utilizing 
multiple window displays. 

3. 3. 1.8 Multiple Users 

The software provides multiple user capability. This capability allows separate users to 
perform simultaneous independent simulations, LRV tests and software development within 
the performance constraints of the host computer, bus traffic and I/O constraints and avionics 
hardware availability. 
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3.3.2 Menu Architecture 

The structure of the multilevel lab configuration software is shown in figures 3. 3.2-1 , 2 and 3. 
Each block on these diagrams represent an individual main program module and menu. The 
top or first block is the Main Status and Allocation menu and attendant Control, Monitor and 
Display, (CD&M), program. This CD&M menu is used to monitor, control and allocate the 
GBT resources. 



(continued) (continued) (continued) (continued) (continued) 


FIGURE 3.3.2-1. LAB CONFIGURATION SOFTWARE: GBT TARGET AND PHASE 1 DESIGNS 

PROGRAM / MENU STRUCTURE 



FIGURE 3.3. 2-2. LAB CONFIGURATION SOFTWARE: GBT TARGET AND PHASE 1 DESIGNS 

PROGRAM / MENU STRUCTURE (CONT) 
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PROGRAM / MENU STRUCTURE (CONT) 


3.3.3 Menu Design 

3.3.3. 1 Main Status and Allocation Menu 

Figure 3.3.3. 1-1 shows a conceptual version of this type of menu. The header or top portion 
and footer or bottom portion of this and most other control menus are similar. The two most 
important areas are the SYSTEM ALERT button/annunciator, in the top left corner and the 
SYSTEM MESSAGE field or footer. These areas are dedicated to the transmission of critical 
operational or safety related information requiring action by current users of the GBT. The 
SYSTEM ALERT will be a predetermined message whose content will indicate the type of 
action required by the current users. The type and variety of message selectable will be 
appropriate to the functions being controlled at the initiating console. A SYSTEM ALERT 
initiation will be a simple two or three step sequence that precludes accidental or 
unauthorized activation. Selection of the SYSTEM ALERT button would access a SYSTEM 
ALERT menu from which the appropriate message could be selected and sent. The 
SYSTEM MESSAGE field may be used for routine status messages. Any Alert type of 
message will be accompanied by an audio signal and the SYSTEM ALERT button will flash. 

The major portion of the Main Status and Allocation display contains a functional block 
diagram of the GBT and its associated resources. In the uper left of this area is the Resource 
Allocation chart. This interactive chart is used to log and schedule current jobs in the GBT. 

As each user is identified and the respective test time scheduled, the required resources are 
selected. As the resources are identified, their assignment is marked with the users ID 
pattern. Two additional detail menus will probably be developed and accessable from this 
main menu. The first will be a series of functional block diagrams of the GBT resources in 
use by each user. The second type of menu will show the hardware allocation to current 
users by GBT functional element. This is the subject of a subsiquent paragraph. 
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FIGURE 3.3. 3.1-1 . CONCEPTUAL VERSION OF MAIN STATUS AND ALLOCATION MENU 


3. 3. 3. 2 Hardware Status and Allocation Menu 

Figure 3.3.3.2-1 shows the Hardware Status and Allocation Menu which might be used for 
the Main Control & Demonstration area of the GBT. This menu identifies all the hardware 
resources within this GBT element, its user assignment, current operational status, and the 
location of the controlling console. More detailed hardware allocations are possible with this 
menu. In this and most other control and allocation menus future use of an imbedded Expert 
System would greatly inhanse GBT operation. At the bottom of the menu is a display 
selection area which permits access to the other Hardware Status and Allocation menus. 
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GBT Hardware Status & Allocation 

Main Control & Demonstration Center 





TIME & DATE 
28 Sept 89 
10:47:39 


Status Control 


123 

1 

1 

2 

3 

1 

1 


2 

3 

1 

— 2 


QML 


G&2L 


G&N 


G&N 


Main Control Processor 
Graphics Processor 1 
Graphics Processor 2 
Graphics Processor 3 
Graphics Processor 4 
Demo Monitor 1 
Demo Monitor 2 
Demo Monitor 3 
Demo Monitor 4 
Laser Printer 1 
Laser Printer 2 
Line Printer 1 

CMCD(3(CoreDCAHB )(li^CG&lO(EimX Act XNavjG>P(SDL) 

System Messages and Alerts 

FIGURE 3.3.3.2-1. HARDWARE STATUS AND ALLOCATION MENU 


ON 

STBY 

STBY 

OFF 

OFF 

STBY 

STBY 

OFF 

OFF 

OFF 

STBY 

OFF 


G&N 


3. 3. 3. 3 Test Control and Monitor Menu 

To the user, the typical Test Control and Monitor menu shown in Figure 3. 3. 3.3-1 may be the 
most important. From this menu the user must be provided the real time control and visibility 
to assure his test will stay within specified limits and yield the reqired data. He must be able 
to quickly select backup menus that provide the level of data required to investigate off 
nominal test results. The menu shown follows the convention of grouping the controls on the 
left of the display with the Emergency Stop button / annunciator at the top. As with the 
SYSTEM ALERT button, this button is activated by a two or three step sequence. Depending 
on the functions involved, its activation would iniciate a preplanned, rapid shutdown of the 
assigned or affected resources. Its activation would automatically iniciate the appropriate 
SYSTEM ALERT. The test control buttons will be mechanized to fit the test requirements. 

The Status fields allow following the hardcopy test proceedures and or rerunning portions of 
preprogrammed tests. Current software tools permit the buttons and fields to reflect changes 
in status or value. Buttons differ from fields primarly in their ability to act as a slector as well 
as an annunciator. The display on the right of the menu is a field in which various important 
test functions can be graphically monitored. The function displayed can be selected from the 
buttons under the display or requested via the message field in the footer. * 
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SYSTEM 

ALERT 


GJ3T TEST Control & Monitor Screen 

Guidance & Navigation System Test - Shuttle C 


TIME & DATE 

28 Sept 89 
10:47:39 


[Emergency 
Stop 
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CONTROL 
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Step If Reset 


Status 
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Step 7-167 


Nominal 


ALT 


Sequence A-7 


Time T+106:58 


Altitude/ Time 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
TIME 
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FIGURE 3.3. 3.3-1. TEST CONTROL AND MONITOR SCREEN 


3. 3. 3. 4 Test Selection Menu \ 

This general type of menu differs basically from those formerly discussed in that it is used to 
link the necessary software modules and datasets to build a test procedure or simulation. 
These programs are indicated in the Integrated Simulation and LRU Evaluation blocks in 
Figure 3.3.3.4-1. .The Test Selection menu shown is the top level selection menu which 
grossly classifies the type of task to be performed, The type of avionics system architecture or 
element and the operational enviroment. It also permits selection of specific, previously run 
tests and or simulations. 
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GBT TEST MENU 


System Tests 

• Shuttle C 
O Centaur 
O OMV 
OSTV 

Hardware Tests 


Mission Phase 

O Prelaunch 
OTermlnal Count 
O Ascent 
Oon Orbit 
ORend & Dock 
O Deorbit 
O Entry 


O IMU 

OApproach 

O FCP 

O Landing 

O INU 
O DAS 

Test Mode 

O RVU 

O System Sim 

O MDU 

O Acceptance Test 

O RDU 

O Other 



TIME & DATE 

28 Sept 89 
10:47:39 


Test Library 

O Shuttle C Int 
O Shuttle C 
OProp 
OALS Int 
OALS Core 
STVInt 


System Messages and Alerts 


FIGURE 3. 3. 3.4-1 . TEST SELECTION MENU 


3.3.4 Simulation Models 

All program modules and menus are generic, i.e., the menu structure changes for different 
simulations and lab configurations. All elements are data driven either by user defined data 
files and/or user commands from the keyboard. The software design goal is to not require 
new software modules to be written (coded) as a new simulation is defined. 

3.3.4. 1 Mission/Vehicle/Environment Models 

Simulation software is provided to support avionics testing in simulated ascent, orbital and 
controlled reentry phases. The fidelities and frame types of the software modules are 
variable and selectable using data files. As a minimum, software modules are provided to 
support components shown in figure 3.3.4. 1 -1 . 

3. 3. 4. 2 Avionics Simulation Models 

Simulation software is provided to functionally simulate avionics hardware. The software 
models are structured to allow for the testing of redundancy concepts such as multiple sets of 
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avionics (hardware and/or software simulation), cross-channel communications, 
synchronization and shielding. Software modules are provided to support the components 
shown in figure 3.3.4.2-1. 


SIMULATION MODULE DESCRIPTIONS 

. 6 DOF DYNAMICS - PROPAGATES 6 DOF DYNAMICS FOR EACH VEHICLE 

• MASS PROPERTIES - CALCULATES TIME VARYING VEHICLE MASS PROPERTIES BASED ON FUEL 
CONSUMPTION AND VEHICLE STAGING / SEPARATION EVENTS 

• AERODYNAMICS - CALCULATES AERODYNAMIC FORCES USING LOWER AND UPPER ATMOSPHERES AND 
REENTRY MODELS 

• BODY BENDING - CALCULATES VEHICLE BENDING EFFECTS BASED ON VEHICLE STIFFNESS AND/OR 
BENDING MODES 

• SLOSH - CALCULATES FUEL SLOSH EFFECTS ON VEHICLE ACCELERATIONS AND CG 

• MAIN ENGINES - CALCULATES ENGINE THRUST AND FUEL USE BASED ON LOW AND HIGH FIDELITY 
ENGINE MODELS 

• REACTION CONTROL SYSTEM (RCS) - CALCULATES RCS EFFECTS AND FUEL USE BASED ON LOW AND 
HIGH FIDELITY RCS AND RCS FLUIDS MODELS 

• ACTUATORS - CALCULATES ACTUATOR POSITIONS BASED ON LOW AND HIGH FIDELITY ELECTRO- 
MECHANICAL ACTUATOR MODELS 

• THRUST VECTOR CONTROL (TVC) - CALCULATES THRUST VECTOR FORCES BASED ON ENGINE THRUST, 
ACTUATOR POSITIONS, AND VEHICLE BENDING EFFECTS 

• ENVIRONMENT - CALCULATES ATMOSPHERIC PARAMETERS BASED ON ALTITUDE, SIMULATES 
DISTURBANCES AND WIND EFFECTS 

• HARDWARE / SOFTWARE INTERFACES - PROVIDES I/O ROUTINES FOR HARDWARE IN THE LOOP, I/O 
SIMULATIONS FOR SIMULATED HARDWARE 


FIGURE 3.3.4. 1-1. PHASE 1 SIMULATION MODELS: 


DESCRIPTIONS 

■ NAVIGATION - SIMULATES INERTIAL SENSORS AND FLIGHT CONTROL PROCESSOR FUNCTIONALITY AND 
INTERFACE ELECTRONICS 

■ VOTING LOGIC - SIMULATES VOTING LOGIC FUNCTIONALITY AND INTERFACE ELECTRONICS 

• DATA ACQUISITION - SIMULATES DATA ACQUISITION, REDUCTION AND TRANSMISSION AND INTERFACE 
ELECTRONICS 

• ENGINE CONTROLLER - SIMULATES ENGINE CONTROLLER FUNCTIONALITY AND INTERFACE 
ELECTRONICS 

• RGU AND AA - SIMULATES RATE GYROS AND ACCELEROMETERS 

• CROSS-CHANNEL COMMUNICATIONS - PROVIDES CROSS-CHANNEL DATA LINK BETWEEN AVIONICS 
MODULES (HARDWARE AND/OR SOFTWARE MODELS) 

• SYNCHRONIZATION AND SKEWING - SYNCHRONIZES WITH HARDWARE AND PROVIDES ARTIFICIAL 
SKEWING TO SOFTWARE MODELS 

• INSTRUMENTATION - SIMULATES DATA NECESSARY FOR DAS OPERATION 


FIGURE 3.3.4. 2-1. PHASE 1 SIMULATION MODELS: - AVIONICS SIMULATOR MODELS 


3.4. GBT Design Concept Demonstrations 

A series of demonstrations was performed to validate several GBT design concepts. The first 
was performed during the Shuttle C Users Group meeting in May. The second was done in 
late June and coincided with an Advanced Launch System meeting. The September 
demonstration marks the end of the HLCV study contract extention and is the most ambitious 
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and significant to date. Due to interest expressed by ALS, a demonstration is being 
proposed for the early December 1989 time frame. 

3.4.1 May Demonstration 

* 

Figure 3.4.1 -1 is a functional block diagram of the first demonstration performed in the MSFC 
Building 4487, Guidance Lab. Though origionally planned as an Open-Loop test of a 
candidate Shuttle C Guidance and Control system, the actual demonstration closed the loop 
around a prototype Inertial Navigation Unit, (INU). As shown in the diagram, The INU was 
mounted on a computer controlled, three axis table. The Shuttle C vehicle dynamic model 
and Flight Control processor models resided in the G&N lab computer. Simulation control 
and monitoring was the function of the Inertial Navigation System, (INS), Test Station. 
Additional visibility was provided by a Graphics Workstation. 

In addition to the demonstration in the Guidance Lab, a display of an INU prototype was 
provided at the Shuttle-C Engineering Design Unit. The INU was mounted so it could be 
manually displaced in any of its sensitive axis and its output was monitored. 
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FIGURE 3. 4. 1-1 


MAY DEMONSTRATION 


3.4.2 June Demonstration 

The June G&N demonstration was similiar to Mays except the dynamics model of the ALS 
was used with the ALS Flight Control processor model. These models were resident in the 
INS Test Station for this simulation. Two other demonstrations were also presented showing 
Adaptive Guidance Navigation and Control applications for ALS and an Expert System 
tanking proceedure. 
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3.4.3 September Demonstration 

Several additional elements of the GBT were demonstrated in September. These included 
several hardware and software products. Supplementing the prototype INU was a s'eperate 
Flight Computer which contained its flight software coded in Ada. A brassboard Remote 
Voting Unit, (RVU) was used to process Trust Vector Control, (TVC), commands from the 
Flight Computer. The resulting analog output was interfaced with an actuator model residing 
now in the Compaq workstation. A small Electro-Mechanical Actuator was also driven by 
workstation converted TVC commands. 

The GBTs name, having gone through several changes, is now the AVIONICS 
PRODUCTIVITY CENTER, (APC). Figure 3.4.3-1 is the MSFC chart showing the updated 
APC functions. New among the articles under test are Controllers and Pilot Station. 


AVIONICS PRODUCTIVITY CENTER (APC) 
FUNCTIONAL DIAGRAM 



FIGURE 3. 4.3-1 APC FUNCTIONAL DIAGRAM 
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3. 4. 3.1 Demonstration Objectives 

Figure 3.4.3.1-1 is a functional block diagram of the September demonstration. There were 
two general objectives / tasks sited fdr this third demonstration. Control Dynamics w&s to 
provide and demonstrate. a new modular vehicle dynamics model. They were to be able to 
demonstrate that model using a model of the Rockwell Shuttle avionics to close the loop. 
General Dynamics was to then integrate into the simulation the following hardware and 
software: 


• An Ada coded Flight Computer capable of controlling a Shuttle C during ascent 

• A Remote Voting Unit capable of processing TVC commands and data 

• A prototype Electro-Mechanical Actuator controlled by TVC commands 



FIGURE 3.4.3.1-1 SEPTEMBER DEMONSTRATION 


Aditionally, a demonstration of the user friendly APC control and program development 
software was requested. 
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3. 4. 3. 2 Modular Vehicle Dynamics Software 

The APC software is required to be modular and dataset driven. The Control Dynamics, 

(CDy) vehicle dynamics software, developed for September, was to demonstrate these 
characteristics. During the demonstration briefing, CDy showed the modules selected for the 
program in use plus others that could be added later. Because of the limited capacity of the 
current G&N Lab computer, modules such as body bending and propellent slosh were not 
included. Winds and aerodynamics were included in the demonstrated vehicle dynamic 
model. 

3. 4. 3. 3 Shuttle C, Hardware in the Loop Demonstration. 

The CDy vehicle dynamics program resided in the G&N Honeywell XPS100 computer. It is 
controlled and monitored via the Sun graphics workstation. During the two September 
demonstrations software only and hardware in the approximately the same ascent profiles 
were displayed on the workstation making a direct comparison possible. 

The Shuttle C flight control software resided in the Motorola 6830 VME modular computer. 
The ascent profile is determined and controlled by the flight control software. Vehicle angular 
position and rates were provided by the G&N lab 3-axis table. The MAPS sensed these 
angular displacements and transmitted this rate and attitude data over the 1553 vehicle bus 
to the Flight Computer. TVC commands are sent from the Flight Computer to the RVU, via 
the 1553 vehicle bus, where they are processed into the individual TVC channel command 
signals. Actuator Position is fed back to the Flight Computer and to the G&N lab computer. 
This actuator position data is factored into the vehicle dynamics calculations and appropriate 
commands are sent to the 3-axis table, thus closing the loop. The remaining avionics system 
hardware functions are simulated in the COMPAQ workstation. 

A TVC Electro-Mechanical Actuator was driven by the Compaq workstation using the#1 
Shuttle C Main Engine pitch channel commands. This small ICBM EMA and its controller 
were provided by Allied Signal and represent the typical interface requirements which must 
be accommodated by an avionics system. The RVU will have the capability to interface 
directly with the EMA controller in subsequent demonstrations via its analog input/output 
modules. 

3.4.4 Proposed December Demonstration 

The'December Demonstration, like those that preceeded it , will be a proof of concept 
demonstration that combines the APC functions previously shown with new key functional 
elements. The major elements to be demonstrated include high speed lab to lab data 
communications and integration of the new Propulsion System Lab resources into a closed 
loop ALS system simulation. Figure 3. 4. 4-1 is a functional block diagram of the December 
demonstration. 

3. 4. 4.1 Lab to Lab Data Communications 

Realizing the APC goal of linking existing and future lab resources with a central integraton 
lab rests heavly on high speed data bus technology. It relies on the data networks ability to 
accomodate the growing bus traffic levels associated with real time operation. Pronet 80 was 
chosen by MSFC to be the initial high speed data bus network for lab to lab data 
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communications. The December demonstration will utilize Pronet 80 to link the new Simstar 
computer in building 4476 to the balance of the equipment in building 4487s G&N Lab. The 
fiber optic cable used to link the two facilities should exceed 500 feet thus providing a good 
initial example of transmission capabilities at that moderate range. Successful integration of 
the software drivers and 'communication overheads into lab operations software will also be 
shown. 

3. 4. 4. 2 Integration of New Propulsion Lab Resources. 

The new Simstar computers capability to provide a real time, high fidelity simulation of the 
current Shuttle Main engine will be integrated into the GDSS ALS avionics system 
simulation. Throttle commands will be generated by the Flight Computer and sent to the RVU 
via the 1553 vehicle bus The throttle command will be linked to the Engine Simulation over 
the Pronet 80 link to the Propulsion Lab. Engine thrust level and throttle position will be fed 
back to the G&N lab over the same Pronet 80 link. The Engine thrust level will be summed 
with the other engine thrust vectors being calculated in the vehicle dynamics model. A pair of 
high fidelity TVC actuator models for the same engine will hopefully be avalable so the thrust 
vector may be completed at the same level of fidelity. If this is realized, the TVC actuator 
commands and positions could also be sent over the Pronet 80 link. 
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FIGURE 3.4.4-1 PROPOSED DECEMBER DEMONSTRATION 
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